Is it ‘software developer’ or ‘software engineer’? And then there’s ‘systems analyst’ and ‘analyst-developer’ to throw into the mix. For managers running software teams and recruiting software practitioners, titles can be confusing – even resulting in hiring the wrong people. It’s so difficult to see just what competencies are needed, let alone find and hire someone with them.

What's in a name?

Software engineering has been cited by Forbes, the US media firm, as the number one career. Salaries for software practitioners in the UK range from about £35k to £150k. And there simply aren’t enough good software practitioners to satisfy worldwide demand.

So how does a manager determine the skills and knowledge needed for their projects?

To answer, we need to deconstruct the job titles and try to develop a grey-scale of competency. And actually, it’s quite straightforward when one relates the skills and knowledge to the job to be done.

And let’s not get bogged down in the detail. It does not matter if a waterfall or agile project lifecycle is adopted for the software projects. We need to dump the jargon and get to what people do, rather than focus on management’s intended method of working.

The generic lifecycle of a software project starts with a need of some sort on the part of a user. Often, it’s not the user themselves that expresses the need but their manager. It’s here that the software (or solutions) analyst gets to work, eliciting the requirement. Requirements elicitation and elaboration is not an easy task. Analysts working in this area are at the top of the salary range.

If there’s an arm’s length relationship between the company that has the need and the company that will satisfy the need, this requirement forms the basis of a contract between the two. If the two are in the same organisation, it might be ‘wooden dollars’ and tacit arrangements – and there might be more leeway to trade function for price.

System acceptance

Going to the other end of the generic project lifecycle, the elicited requirements then form the essence of the activity whereby the requestor accepts what’s been done for them. Acceptance is a milestone. It’s a point where the software practitioner asks the requestor if they are satisfied, if what was agreed to be done has indeed been done.

For many software developers, this part of the project is someone else’s responsibility. It’s a contractual activity, because if what was agreed to be done is not done, someone must take action – or the requestor must agree that it’s OK not to do it. Software engineers understand acceptance well – their clients are sometimes external firms and sometimes internal departments. In agile methods, clients are represented by product owners attached to the development team.

These two activities – requirements elicitation and acceptance – are delicate times that demand very special skills and knowledge and unique personality and inter-personal skills. For those software developers whose training has focussed on code, this is their weakness.

System Architecture

Today, many practitioners consider systems architecture as set. There’s a database, algorithms, some business logic and a user interface. Most user interfaces exploit web technology. But architecture is inextricably linked to design – the way the software is laid out. And for many professional systems, architecture is far from set. Architecture is often a key source of competitive advantage for organisations using software systems. Systems architects have those software architecture skills.

And code is needed right from the user interface all the way back to the database. Code is needed in various modules that comprise the design.

And then there’s the activity in the middle – development. That gives rise to the job title ‘software developer’. It’s what they do. Assuming all the other parts of the lifecycle, software developers develop the code that makes the system work to meet the agreed requirement. How exactly that’s done, the iteration that’s needed and the number and length of agile sprints depend on how well the requirement is known. They also depend on the contract between requestor and provider.

Typically, testing is also separated from code development. Indeed testing has become a specialist domain embracing the development of automatic test tools. Testing is done at many levels from testing code written in modules through to testing the complete system, as it will be presented to the users.

Software project management

To complete the picture, we have to go wide again. Someone must estimate the effort needed to provide the requirement. Effort translates in any development scenario to money. If it’s an arms’ length arrangement, the requestor will pay the provider for supply of a system that’s compliant with their requirement. If it’s internal, the requestor will have to raise the budget with senior management.

Someone with software practitioner skills must also represent the provider in discussions with the requestor. For separate entities, that’s usually done via a business-to-business supply contract. It could even be two executives shaking hands on the deal. Internally, it could be just a tacit agreement between two managers.

And once the system is realised and tested compliant, someone must put the system into use with the users. Users will need to be trained. And on-going activities must assure the requestor, on behalf of the users, that the system will continue working in a defined context for an agreed time.

While these start and end activities are often considered ‘commercial’ and not part of the software practitioner’s bag, they are still software engineering tasks.

Deconstructing software roles

So, we can understand the software engineering job by referring to both the lifecycle and the architecture. Software developers are those who see their skills and knowledge best suited to producing the code, while someone else takes responsibility for the other lifecycle parts. By taking a relatively narrow slice of the action, software developers enjoy salaries at the lower end at around £45k to £65k. Software testers are specialists in making sure the code and system are compliant with the requirements – however it is that those requirements are presented and developed. That specialism further reduces their achievable salary to between £35k and £55k.

Systems architects think spatially about how the various system components are to be applied and designed. And analysts think wider still about how the users will be afforded the benefit they seek. Analysts and architects are typically paid towards the upper end of the salary range at £55k to £85k.

Greyscale of software careers

On entering software engineering, a recent graduate from a good university would typically go into one of the ‘lower’ specialisms – test or development. Some will specialise even more to work initially on user interfaces or databases before expanding their competencies to work ‘full stack’. They’ll then be trained (or find their own training) to evolve to take on more lifecycle activities.

Ultimately a software engineer should be capable of applying themselves across the commercial activities of contracts through the software production activities of design and development and out to testing, acceptance, implementation and maintenance. They’ll manage others in the specialisms to achieve a compliant solution. Then they’ll command in excess of £100k in salary.

So, there’s the grey-scale. The job that a software professional does is linked to where on the lifecycle they work and how much of that lifecycle they embrace. It also depends on how much of the technology they cover – user interface or full-stack. And salaries go with those definitions.

If you are trying to set up a software team, or are trying to recruit and manage software engineers and would like practical help, call us.